MODULE 5 CLOSURE
Spring 2010
Compiled by Greg Kinney
“MUDDIEST ITEMS”
QUESTION:
The least clear item in the module involved use of participative management and the representative models. Finding better ways to accomplish a task or a project is a great idea, but the methods or programs, e.g. MBO, EI, Six Sigma, TQM, SDWT, etc. are not detailed enough to understand how the methods or programs actually work. More detail about the methods and their effectiveness would have helped.
ANSWER:
Fair enough. Of course some of this is very involved. Six Sigma training takes several courses to complete. But they could have had a little more detail.
QUESTION:
For me, the muddiest item in the module was definitely the concept of the technical change procedure. I understood the definition of it based upon the question about it in the quiz but I didn’t feel that the book itself was very clear on the subject when it was discussed.
ANSWER:
I believe that the term “technical change” is chosen because the author wanted to draw a distinction from project approach changes (i.e., sequencing, change in construction method, contractor change, etc.). A technical change procedure is needed to control both the tendency toward “scope creep” and an uncontrolled drift away from accomplishment of what was agreed on in the first place. In terms of the big picture – i.e., the scope of work – that consists of a broad statement of what is to be accomplished. If something significant is added or deleted to that, then that requires an amendment to the Scope of Work which should be endorsed by the client and project sponsor. For changes or amendments to engineering details, you need to have a clear procedure for a Design Change Request (which goes by a lot of names), which is reviewed and approved or modified by Engineering, tracked on a log and redlined on the prints.
You will find much more on this in Chapter 11, Section 11-7, which we will get to in a few weeks.
QUESTION:
The ‘muddiest’ thing from this module was that the pure project as well as the matrix structure had almost as many disadvantages as they did advantages.
ANSWER:
That is absolutely true! Any form of organization you choose has pros and cons. That said, it’s pretty clear that most project management authors like the projectized organization structures and recommend them. This can, however, create problems in the overall organization. The authors point out the phenomenon of “suboptimization” wherein you optimize the heck out of one part of the enterprise, but that optimization comes at the expense of efficiency somewhere else. Unfortunately, a pure project organization within a larger organization can be a good example of that.
QUESTION:
The book states, “Every project should have a project office, even if it must be shared with another project.” This seems very intuitive to me, and I’m surprised it is even made into a point. How would it be done otherwise?
ANSWER:
I believe the authors are trying to get away from the practice, still employed at some organizations, to treat projects as an afterthought, with project management functions to be performed by part-timers as fill-in time for other work. For small jobs, that might work OK, but for larger projects, it is obviously dysfunctional. For those of us in the business, this is not new.
QUESTION:
The least clear thing I learned from this module was at what size of firm to project management offices get implemented? They seem like a good idea, but only for large corporations. Also, do any government agencies have project management offices?
ANSWER:
I don’t think there is any clear answer as to what size of organization is needed to support a PMO. I think it really is more an issue of how many projects are being undertaken, and what is the complexity of them, and how does it impact the overall organization. Where I work (Alyeska Pipeline) there is still not a full implementation of the PMO concept, though there is a Projects organization. I believe we would benefit from a PMO, however. As to government agencies, I am sure that there are some having PMOs, but I can’t identify any without research. I would note an article I found on the Web dealing with this issue (copy and paste to browser if hyperlink doesn't show): http://www.theicpm.com/articles/pmo/247-implementing-a-pmo/425-using-a-pmo-to-achieve-results-in-your-agency
QUESTION:
When I try to find my solution to question number 1, I wish that the book explains a little bit more how a program manager does its job. Other than that, I like reading this chapter, and gain lots of insights.
ANSWER:
I think this is a course in its own right, one that I would be unprepared to teach because I have neither training nor experience in program/portfolio management. I would note that there is a program management certification now offered by PMI (PgMP), and the PMI bookstore includes a number of references, The certification is at http://www.pmi.org/CareerDevelopment/Pages/AboutCredentialsPgMP.aspx (cut and paste to browser) and books can be found at http://www.pmi.org/Marketplace/Pages/default.aspx?Category=Program+Management .
QUESTION:
The muddiest part during this module is the second question in Quiz 4. I think when a PM conducts a project, he always deals with how to manage diverse changes. Because the project itself is a change to normal or routine operations. So I think the PM could do anything possible to control the change. Why is the answer “he should establish a technical change procedure”? What does “technical change procedure” exactly mean? Is it introduced in the textbook or somewhere else?
ANSWER:
I believe that the term “technical change” is chosen because the author wanted to draw a distinction from project approach changes (i.e., sequencing, change in construction method, contractor change, etc.). A technical change procedure is needed to control both the tendency toward “scope creep” and an uncontrolled drift away from accomplishment of what was agreed on in the first place. In terms of the big picture – i.e., the scope of work – that consists of a broad statement of what is to be accomplished. If something significant is added or deleted to that, then that requires an amendment to the Scope of Work which should be endorsed by the client and project sponsor. For changes or amendments to engineering details, you need to have a clear procedure for a Design Change Request (which goes by a lot of names), which is reviewed and approved or modified by Engineering, tracked on a log and redlined on the prints. The question, it is noted, is mostly a common sense one (the question suggests the answer), and the subject is mentioned in passing at the bottom of page 212. Substantive discussions on this topic can be found in Section 11.7, page 572, which we will get to in a few weeks.